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PREFACE 


This is a reference manual document describing the requirements for 
the HAXi/SM programming system to be developed to provide the ability to use 
the HAL programming language in the SUMC/MOSS environment. 

This document is partially based on, supplements, and in part, super- 
cedes the Higher Order Language (HOL) Preprocessor Requirements Specifi- 
cation Document (Reference 8). As such, this document and the HAL/SM 
Language Specification (Reference 1) shall be the final controlling specifica- 
tions for HAL/SM software. 

Section 1 of this document discusses the basic structure and major 
objectives of the system. Section 2 describes the major subsystems of the 
implementation and their functional requirements. Section 3 details the 
interfaces between the major subsystems and implicitly defines their pro- 
cessing requirements. Section 4 discusses restrictions and limitations in- 
herent in the implementation* 
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INTRODUCTION 


The HAL/SM programming system shall implement a version of the 
HAL programming language (see Reference 9) which has been specifically 
adapted for running in the Concept Verification Test (CVT) environment on 
the Space Ultrarellable Modular Computer - Simplex (SUMC-S) under the 
Modular Operating System for the SUMC (MOSS), The HAL/SM programming 
language is defined in the HAL/SM Language Specification (Reference 1, re- 
ferred to herein as the Language Spec); familiarity with the Language Spec 
shall be assumed throughout this document. 

The HAL/SM programming system shall be implemented as an adapta- 
tion of the HAL/S-360 Compiler System, Release 11*0 (see References 3 
through 5), and shall consist of a HAL/SM Preprocessor, the HAL/S-360 
Compiler, and modified versions of the HAL/S-360 HALLINK program and 
Run Time Library (RTL), The preprocessor, compiler, and HALLINK 
(collectively referred to herein as the language processor system) shall all 
operate on the IBM S/360-370 family of computers under suitable operating 
systems as specified in Reference 4, The HAL/SM object programs produced 
by the language processor system when properly combined with the RTL and 
linked in the MOSS environment (see References 6 and 7) shall be capable of 
executing under and utilizing the full capabilities of the MOSS Operating System 
on the SUMC-S computer system. 
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2 . 


SUBSYSTEMS 


The major subsystems of the HAL/SM system shall be as follows (see 
Figure 2-1): 

o HAL/SM Preprocessor - converts HAL/SM source language 

modules into HAL/S source language modules, performs 
minimal syntax verification, provides various support 
features which cannot be conveniently or adequately per- 
formed by the HAL/S-360 compiler (e.g., M&CD reference 
verification, C&D display message data set generation). 

o HAL/S-360 Compiler - converts HAL/S source language 

modules into IBM S/360 compatible object modules, per- 
forms complete syntax verification, 

o HALLINK - combines HAL/S object modules into load 

modules, calculates run-time stack size requirements 
and adds the stack to the load module, adds and/or deletes 
certain other CSECTS from the generated load module 
depending on options specified, 

o Run Time Library - when properly linked with each HAL/ 

SM task, provides computational routines and MOSS inter- 
face routines to support various features of the HAL/SM 
language. 

The functions and interactions are described in more detail in the 
remainder of this section on an individual subsystem basis, except for the 
compiler. For more information on the compiler, see References 2 through 5, 

2. 1 Preprocessor Subsystem 

This subsection describes the functional requirements for the HAL/ 

SM preprocessor. In this implementation of HAL/SM, the combination of the 
preprocessor and the HAL/S-360 compiler takes the place of a HAL/SM- 360 
compiler. This approach to language translation has the advantage of being 
considerably less costly than a compiler development effort. To take full 
advantage of this fact, the requirements for the preprocessor have been 
specified with the following ground rules in mind: 

o Minimize complexity by making no modifications to 

the HAL/S-360 compiler. 
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Figure 2-1 
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o Perform no processing in the preprocessor which can be 

performed by the HAL /S- 360 compiler. 

Within these constraints the requirements listed in the following paragraphs 
have been defined such that the preprocessor will provide the same facilities 
as would otherwise be provided by a HAL/SM compiler. The single major 
area where this is not possible is in syntax error detection and diagnostic in- 
formation (see Section 2, 1,6). 

The remainder of this subsection is divided into detailed requirements 
specifications by major functional area of the processing performed by the 
preprocessor (see Figure 2-2). 

2.1.1 Inputs 

The preprocessor shall accept two classes of primary inputs: HAL/ 

SM symbolic source code and directives. An additional input shall be the 
Program Access File, 

Symbolic Source Code: The preprocessor shall accept HAL/SM 
source code In the one-dimensional form defined in the Language 
Specification, Symbolic source code may be presented to the 
preprocessor from either a primary input data set (default; nor- 
mally from the card reader) or a secondary input data set, as 
specified by preprocessor directives. The secondary input data 
set is called the Symbolic Library and contains block templates 
generated by the preprocessor and other standard symbolic 
modules which may be placed in the library using standard IBM 
supplied utility programs. 

Directives : Directives shall provide control information required 
by the preprocessor and the compiler. The preprocessor shall 
accept two types of directives: 

o HAL/SM preprocessor directives (denoted by a "P" 

in column 1 of the input record), 

o HAL/S-360 compiler directives (denoted by a "D" in 

column 1 of the input record). 

Certain of the directives defined for the HAL/S-360 compiler (see Reference 6) 
shall be restricted from use by the preprocessor in the HAL/SM system (TBD). 
These directives shall be replaced by preprocessor directives of the same 
form and intent. All other compiler directives shall be passed by the pre- 
processor to the compiler in the compiler's primary input data set. Additional 
preprocessor directives shall be defined to control optional processing performed 
by the preprocessor. 
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Program Access File (PAF) ; Implementation of the HAL/SM ACCESS 
attribute shall be via a PAF mechanism of the same form and intent as 
in the HAL./S-360 implementation (see Reference 5, paragraph 6, 2, 2, 6), 
Although this capability is contained in the compiler, it must be dupli- 
cated in the preprocessor because of certain transformations made by 
the preprocessor to the text of the preprocessed symbolic modules, 

2.1.2 Symbolic Library Interface 

The Symbolic Library facility of the HAL/SM system shall be imple- 
mented via a mechanism of the same form and intent as that of the HAL/S-360 
Include Library (see Reference 5, paragraph 6, 2, 2, 5). 

All block templates generated by the preprocessor shall be placed in 
the Symbolic Library, Template generation shall be performed in a manner 
similar to that performed by the compiler (see Reference 5, paragraph 6. 2, 2. 7) 
differing only as dictated by the definition of the HAL/SM language. 

2.1.3 M& CD Interface 

The preprocessor shall verify all references to ERP's made by the 
HAL/SM programmer by looking up the M&CD ID in the M&CD, All. references 
to ERP’s shall be checked for correct usage and the reference will be tran- 
slated to the standard "O-name" defined for that particular ERP to permit 
processing by the MOSS Linker. 

2.1.4 Display Data Interface Utility (DDIU) Interface 

The preprocessor shall remove all C&D display message text from the 
HAL/SM source code and create a data set which contains this information. 

The data set shall be constructed by the DDIU routines. Coded references to 
the display data set shall be placed in the output HAL/S code where each 
message is referenced, 

2.1.5 Listings 

Several types of listings may be generated by the preprocessor as 
specified by preprocessor directives. Some or all of these listings may be 
optional (TBD), 

Unformatted Source Listing; This shall be an "80-80" listing of 
the primary input data set and all INCLUDEd text (from the Symbolic 
Library) before annotation or reformatting by the preprocessor. 
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Reformatted Source Listing: This shall be a reformatted and annotated 
representation of the symbolic HAL/SM source text. Indentation and 
annotation shall be in essentially the same form as the primary listing 
produced by the compiler (see Reference 5, paragraphs 3. 1-3. 3), 

Cross Reference Listing : This shall be an alphabetized listing of all 
programmer -defined symbols together with a list of the line numbers 
referencing each occurrence of each symbol in the reformatted source 
listing. 

Output Source Listing : This shall be a listing of the HAL/SM symbolic 
source code produced by the preprocessor. 

2*1,6 Diagnostic Information 

The preprocessor shall produce diagnostic error messages for all 
errors which it detects. These error messages shall consist of descriptive 
text indicating the type of error detected and they shall be placed in the re- 
formatted source listing to indicate the source of the error. 

The preprocessor shall not perform a complete syntactic or semantic 
analysis of all statements. However, sufficient analysis shall be performed 
such that errors not detected by the preprocessor shall cause incorrect HAL/S 
symbolic code to be produced and the compiler will detect the error; i, e. , 
syntactically incorrect HAL/SM source text will cause an error message to 
be generated by either the preprocessor or the compiler or both. 

2.1.7 HAL/S-360 Compiler Interface 

The implementation shall provide for automatic invocation of the 
compiler to process the HAL/S code produced by the preprocessor when no 
errors are detected. All information required by the compiler shall be provided 
to it by the preprocessor when the HAL/SM code is error free. This includes 
certain control information in the form of compiler directives (see Reference 

5). 

The version of the compiler system to be used in the HAL/SM system 
shall be fixed at Release 11,0 for the entire duration of the software develop- 
ment phase, 

2.1.8 User Interface 

OS/ 360 -370 JCL procedures shall be implemented to permit convenient 
use of the HAL/SM preprocessor. Suitable options and defaults shall be defined 
and Implemented into the procedures to allow for the normal expected range 
of applications of the system. 
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2, 2 HALLINK Subsystem 


The HAL/S-360 HALLINK program (see Figure 2-3) is defined to 
produce program complexes which operate in a different environment 
from that of MOSS and it, therefore, performs certain processing which 
is unnecessary for HA L/SM programs, HALLINK also allows certain 
configurations of programs which are not valid in the HAL/SM System, 
This subsection describes the functional requirements for modifications 
to be made to the HAL/S-360 HALLINK program to make it usable and 
reliable within the HAL/SM System, The modified version of HALLINK 
shall be known as the HAL/SM HALLINK program. 

The modifications to be made to HALLINK are primarily to en- 
force restrictions which must be imposed either as a result of the' HAL/ 
SM language definition and the MOSS environment or as a result of the 
implementation of the HAL/SM System, Building these restrictions 
into HALLINK will permit a certain degree of integrity to be guaranteed 
when including non -HA L/SM modules in a HAL/SM task. 

The HAL/SM HALLINK program shall operate in the same manner 
as that for HAL/S->»360 with the following changes; 

o Only one process shall be permitted in each address 

space, 

o Certain control sections shall be deleted from the 

output load modules which are not needed in the 
MOSS environment, 

o The Execution Monitoring System (see Reference 5, 

Section 4,3) shall not be supported, 

2, 3 RTL Subsystem 

This subsection describes the functional requirements for modifi- 
cations to be made to the HAL/S-360 RTL (see Figure 2-4) to make it 
usable under MOSS in the HAL/SM System, 

2, 3, 1 Efficiency Criteria 

The configuration of the particular SUMC-S for which this imple- 
mentation of HAL/SM is to be designed is currently envisioned as a 
system on which main memory is more of a scarce resource than pro- 
cessor time. For this reason, the primary efficiency criteria to be 
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HAL/SM RUN-TIME LIBRARY (RTL) 



Figure 2-4 
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used in implementing the required modifications to the RTL shall be as 
follows; 

o Main Memory requirements shall be kept to a minimum. 

o Execution speed shall be considered secondary to 

memory utilization, 

2.3.2 Modifications to Support MOSS External Interfaces 

Modifications shall be made at all operating system interfaces due 
to different implementation of similar functions. Some RTL modules and 
interfaces shall be deleted where their functions are not supported; others 
shall be added to support new capabilities. Some functions which were 
previously performed (or simulated) within the RTL shall be performed 
by MOSS (e, g, , task scheduling), 

2.3.3 Modifications to Support HA L/SM Calling Sequences 

Modifications shall be made to the RTL to provide Interfaces to 
the HAL/SM program for all new calling sequences generated by the pre- 
processor (see Section 3,1), Some of the new interfaces shall be modified 
versions of existing modules, while others shall require implementation 
of completely new modules to support language mechanisms, 

2.3.4 Unsupported Functions 

Major deletions shall be made from the RTL of modules which handle 
functions which are unsupported by this implementation. The major dele- 
tions pertain primarily to the following: 

o ”Pseudo-RTE" - This refers to the RTL routines which 

simulate process scheduling, event management, etc., 
for the HAL/S -360 implementation. These functions shall 
be performed by MOSS, frequently with modified seman- 
tics, 

o Execution Monitoring System - This facility (Including the 

Diagnostic Command Language, see Reference 5, Section 
4.3) shall not be supported for HAL/SM, 

o Multiple Processes - Under MOSS, exactly one process 

(or "task") is permitted per address space. The HAL/ 

SM RTL shall support only one process per copy. 
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o Flight Computer Timing Simulation - This facility shall 

not be supported for HAL/SM. 

o Miscellaneous HAL/S Features not in HAL/SM - Certain 

HAL/S language features are not provided in HAL/SM 
because either the capability cannot be provided under 
MOSS (e.g,, the HAL/S UPDATE PRIORITY statement), 
or because the capability is considered either dangerous 
or difficult to support in this implementation* 

2*3,5 Unsupported Execution-Time JCL Options 

Because of the deletions mentioned in Paragraph 2.3,4, the follow- 
ing execution -time options (see Reference 5, Appendix B) are not supported 

o MSGLEVEL = 2 

o SIMTIME = n 

o SPEED “ n 

o PCBS = n 

o FIRSTPGM = name 

o PROGRAM = name 

o TRACE = n 

o NOTIME 

o FAST 

o DUMPALL = n 
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3. 


INTERFACES 


section defines the preliminary processing requirements of 
each of the major subsystems in terms of their interfaces. As in Section 
2, the HAL/S-360 compiler is not discussed directly; see References 2 
through 5 for more information. Since the relationships of the HAL/SM 
programs to each of the subsystems are quite different, it is useful to 
interpret the term "interface" differently for each subsystem discussed. 
Specifically, for each subsystem the interfaces are discussed as follows: 

o Preprocessor - For each HAL/SM statement type or 

construct requiring a modified implementation in 
HAL/S the emitted HAL/S source code is described. 

o HALLINK - The allowable inputs and the types of infor- 

mation in the output load modules are discussed. 

o RTL - For each new entry point into the RTL defined 

in support of the preprocessor, the calling sequence 
and function performed by the entry point is described. 

For each RTL module whose implementation is affected 
by the difference between the OS and MOSS environment, 
the required modifications are described on a functional 
level. 

In addition to the inter- subsystem interfaces discussed above, the 
user interface is discussed in terms of OS and MOSS JCL requirements. 

3,1 Preprocessor 

This subsection enumerates the HAL/SM constructs which require 
a modified implementation in HAL/S, Each numbered paragraph discusses 
a single HAL/SM construct in the following form: 

3.1,_ Construct Name 
Syntax Diagram 

Emitted HAL/S Code Template(s) 

Notes 

Examples 
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The syntax diagrams are of the same form as those in the language 
specification, though they are not necessarily identical. Non-terminal 
symbols which are not defined in the langxiage specification are defined else- 
where in this subsection. The notes are used to correlate various elements 
of the HAL/SM construct with the emitted HAL/S code and to explain 
differences in alternate versions of the emitted HAL./S code template re- 
quired by options or alternatives in the HAL/SM syntax, 

3.1,1 TASK Header 

HAL/SM Syntax 




1. The TASK in the HAL/SM construct is equivalent to 
PROGRAM in HAL/S. 

2. Access control for HAL/SM constructs is performed 
by the preprocessor. 

Example 

Tl: TASK ACCESS; 

becomes 

Tl: PROGRAM; 
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3,1,2 COMPOOL Header 
HAL/SM Syntax 




Note 

1. Access control for HAL/SM constructs is performed by 

the preprocessor. 

Example 

Cl: COMPOOL ACCESS; 

becomes 

Cl: COMPOOL; 
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3,1.3 FUNCTION Header 


HAL/SM Syntax 



HAL/S Code Template 



Note 

1. Access control for HAL/SM constructs is performed by the 
preprocessor. 

Example 

Fl: FUNCTION (TESTX) SCALAR REENTRANT ACCESS; 

becomes 

Fl: FUNCTION (TESTX) SCALAR REENTRANT; 
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3,1.4 PROCEDURE Header 


HAL/SM Syntax 



HAL/S Code Template 



Note 

1. Access control for HAL/SM constructs is performed by the 
preprocessor. 

Example 

PI: PROCEDURE (PROCl) ASSIGN (ARGUl ) REENTRANT ACCESS; 

becomes 


PI: PROCEDURE (PROCl) ASSIGN (ARGUl) REENTRANT; 
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3,1,5 REPLACE Statement 
HAL/SM Syntax 



Not Applicable, 

Note 

1, The REPLACE statement is processed by the preprocessor 

(i, e,, the preprocessor shall replace each < identifiers with 
the appropriate <: texts). 

Example 

REPLACE ALPHAZ BY +.2 SIN(ALPHAB)“; 


♦ 

BETAG = ALPHAZ - C05(Y); 
becomes 

BETAG = J + 2 SIN(ALPHAB) - C05(Y); 
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3.1.6 JOB Attribute 


HAL/SM Syntax 



VCON 

template 




label ^ ~Q- ^XTERNAl )- ^ROCEDURE ^-(1)- ^ CLOSE 3^ 


^VCON 

label 

.attribute 


-9 ( ^procedure )-( ^nonhal ^ © Q © 0- 


Notes 

1. All <identi£ier>- s declared with the JOB ■•clabel attributed 
shall cause the preprocessor to produce a "<VCON templated 
(at the beginning of the compilation) with the declared identifier 
as its dabel>* and the JOB *< label attributed shall be trans- 
lated into a <VCON label attributed. 

2, All other dabel attributed s shall be handled the same in HAL/S 
as in HAL/SM (i.e., no transformation). 
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Example 


DECLARE 

LOGANAL JOB ACCESS; 

becomes 

LOGANAL : EXTERNAL PROCEDURE; 
CLOSE; 


DECLARE 

LOGANAL PROCEDURE NONHAL (1) 
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3,1.7 Type Specification 


HAL/SM Syntax 




1, DCW arid EVENT keywords appearing in actype speo shall be 
translated into a cbit (32) type speo, 

2, Identifiers declared with a FLAG <type speO shall cause the 
preprocessor to produce a cVCON template^ (see Section 

3, 1,6) with the declared identifiers as its dabet>and the FLAG 
ctype speo itself shall be translated into a <VCON label 
attribute^ (see Section 3,1,6). 

3, All other ctype speo s shall be handled the same in HAL/S 
as in HAL/SM (i.e,, no transformations), 

4, When no initialization is present for DCW type data (see Section 
3, 1, 8), a default value shall be inserted by the preprocessor. 
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Examples 

DECLARE VARCWl DCW; 
becomes 

DECLARE VARCWl BIT(32) INITIAL (HEX»4008600G'); 

and 

DECLARE EV_1 EVENT; 
becomes 

DECLARE EV_1 BIT(32) INITIAL(O); 
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3,1,8 Initialization of DCW-Type Data 




1* This cbit literals shall be an encoded value specifying the 

display control word options specified in the < dew value list> 
in the HAL/SM construct. Any omitted options in the *<dcw 
value list>* shall be assigned default values. 
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Example 


DECLARE 

DCW_1 DCW INITIAL( C YELLOW, lOMM, BLINK OFF, 6 ); 

becomes 

DECLARE 

DCW_1 BIT(32) INITIAL(HEX'202C4000'); 




3,1.9 ON ERROR Statement (Form 1) 
HAL/SM Syntax 




1, This <label> shall be an entry into the RTL to communicate 
the required information to the HAL/SM error monitor, 

2, This <number> shall indicate the error group specified in 
the <error speO of the HAL/SM syntax. 

3, This <: number > shall indicate the error number within the 
selected error group as specified in the cerror speO of 
the HAL/SM syntax. 
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4 . 


This <bit literal > shall indicate whether the SYSTEM or 
IGNORE option was selected in the HAL/SM syntax, and 
whether a flag is to be signaled, 

5, This optional <variable> shall specify the HAL/S variable 
corresponding to the HAL/SM <flag> , when present. 

Example 

LABlrON ERROR- -IGNORE AND SIGNAL FLAG A; 

3:1 — 

becomes 

LABl:CALLRTL ON ERRORl(3, 1, BIN'll', FLAG__A); 
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3,1.10 ON ERROR Statement (Form 2) 



HAL/S Code Template 



Notes 


1. This <label>“ shall be an entry into the RTL to communicate 
the required information to the HAL/SM error monitor. 
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2, This <number> shall indicate the error group specified in 
the <error speo- of the HAL/SM syntax, 

3, This <nutnber>- shall indicate the error number within the 
selected error group as specified in the cerror speo- of the 
HAL/SM syntax, 

4, This dabel> shall be generated by the preprocessor and shall 
be the same identifier as indicated by 6, 

5, This <statement> shall correspond to the <statement>' in the 
HAL/SM syntax. 

Example 

ON ERRORg jGO TO ERREXIT; 
becomes 

DO; 

CALL RTL_ON_ERROR2 (3, 1, G000005); 

EXIT ; 

G000005; GO TO ERREXIT; 

END; 
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3,1,11 OFF ERROR Statement 


HAL/SM Syntax 




Notes 

1, This <label> shall be an entry into the RTL to communicate 
the required information to the HAL/SM error monitor, 

2, This <number> shall indicate the error group specified in 
the terror speo of the HAL/SM syntax, 

3, This <number>* shall indicate the error number within the 
selected error group as specified in the <error speo* of the 
HAL/SM syntax. 
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Example 


OFF ERROR, 

1 :Z 

becomes 

CALL RTL_OFF_ERROR(l, 2) 


3.1.12 SIGNAL Statement 


HAL/SM Syntax 




Notes 


1* This <label> shall be an entry into the RTL to perform the 
required functions. 

2. Each cvariable>- shall specify the HAL/S variable correspond 
ing to each <flag>' appearing in the HAL/SM construct. 

Example 

SIGNAL FLAG_A, FLAG_B; 
becomes 

CALL RTL_SIGNAL (FLAG A, FLAG_B); 
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3, 1 . 1 3 RESET Statement 
HAL/SM Syntax 



HAIi/S Code Template 



1. This <label> shall be an entry into the RTL to perform the 
required functions* 

2* Each < variables shall specify the HAL/S variable correspond- 
ing to each *< event var>- appearing in the HAL/SM construct. 

Example 

RESET EV_A; 
becomes 

CALL RTL_RESET (EV_A); 
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3.1.14 TER^IINATE Statement 
HAL/SM Syntax 



HAL/S Code Template 



1, This dabel>- shall be one of two entry points into the RTL to 
perform the required functions. 


Example 

TERMINATE JOBj 
becomes 

CALL RTL_JTERM; 

and 
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TERMINATE TASK; 


becomes 

CALL RTL_TTERM 



3, 1. 15 ABORT Statement 


HAL/SM Syntax 




1. This <label> shall be one of three entry points into the RTL 
to perform the reqtaired functions, 

2, Each <label> shall specify the HAL/S label corresponding to 
each dabels* in the HAL/SM construct. 
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Examples ■ 

ABORT JOB; 
becomes 

CALL RTL_JABORT; 

and 

LtABORT TASK^l, TASK_2; 
becomes 

L:CALL RTL_ABORTL (TASK_1, TASK 2); 
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3, 1,16 LOG Statement 
HAL/SM Syntax 




1, This dabel>- shall be an entry point into the RTL to perform 
the required functions, 

2, The cchar exp>- shall be the character expression specified 
in the HAL/SM construct. 

Example 

LOG ‘SIMULATION ERROR’ //ERROR_NUMBER; 
becomes 

CALL RTL LOG ('SIMULATION ERROR' //ERROR_NUMBER); 
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3.1.17 UNLOCK Statement 




1, This dabel>‘ shall be an entry point into the RTL to perform 
the required functions, 

2, Each^^label^ shall specify the HAL/S label corresponding 
to each <label>* in the HAL/SM construct. 

Example 

UNLOCK TAKE_OFF; 
becomes 

CALL RTL UNLOCK {TAKE OFF); 
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3,1,18 LOAD Statement 


HAL/SM Syntax 



HAL/S Code Template 



1* This -<label>- shall be an entry point into the RTL to perform 

the required functions, 

2. This dabel> shall specify the HAL/S label corresponding to 

the < labels in the HAL/SM construct. 

Example 

LOAD LOG_ANALYZERj 
becomes 

CALL RTL_LOAD (LOG_ANALYZER); 


- 41 - 








3,1.19 INITIATE Statement 
HAL,/SM Syntax 




1. This <label> shall be an entry point into the RTL to perform 
the required functions, 

2, This < labels shall specify the HAL/S label corresponding to 
the <label> in the HAL/SM construct. 

Example 

INITIATE LOG_ANALYZER; 
become s 

CALLRTLJ;NIT (LOG_ANALYZER); 
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3,1.20 DELETE Statement 
HAL/SM Syntax 




Note 


1. This *<label>- shall be one of two entry points into the RTL 
to perform the reqmred functions. 

Example s 

DELETE JOB; 
becomes 

CALL RTL_JDEL; 

and 

DELETE TASK; 
becomes 

CALL RTL__TDEL; 
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HAL/S Code Template 












where: 



1. This cchar exp> shall correspond to the parameter expression 

to be passed to the scheduled task. 


2. This optional path shall be taken when an cevent exp> appears 

in the HAL/SM construct. The path shall be repeated via a 
feedback loop as many times as there are event variables in 
the event expression. The cnumber^' on this path shall be 
a one (1) the first time through, and shall be incremented each 
time the path is taken for a given HAL/SM construct. Each 
<bit var>- on the path shall correspond to each of the <event 
var> s appearing in the HAL/SM construct. 
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3. This optional path shall be taken when an *< event exp> appears 
in the HAT/SM construct. The path shall be repeated via a 
feedback loop as many times as necessary to initialize the 
array with the Reverse Polish representation of the cevent exp> 
(see Reference 7, Section 5.2. 1). The <number>* on this path 
shall be one the first time through, and shall be incremented 
each time the path is taken for a given HAL/SM construct. 
Each<bit var> on the path shall correspond to the code for 
either an event operand in the HAL/SM construct or operator 
according to the conventions specified for MOSS event expressions. 

4. This *<label> shall be an entry point into the RTL to perform 
the required functions. 

5. This <bit literal> shall be a bit vector indicating the presence 
of certain optional parameters in the RTL invocation. 

6. This -<label> shall be the HAL/S label corresponding to the 
task label (of the task being scheduled) in the HAL/SM construct, 

7. This carith exp>- shall correspond to the ctime value> in the 
IN or AT phrase of the HAL/SM construct, when present. 

8. This optional path shall be taken when an cevent exp> appears 
in the HAL/SM construct. The ■< number indicates the number 
of <event var> s present in the *<event exp>, 

9. This optional path shall be taken when a THEN WAIT phrase 
appears in the HAL/SM construct. The carith exp> shall 
correspond to the ctime valued in the HAL/SM construct. 

10. This optional path shall be taken when a REPEAT phrase 
appears in the HAL/SM construct. The <arith exp> shall 
correspond to the <time value> in the HAL/SM construct when 
the AFTER clause is present and shall be zero when it is 
absent. 

11, This optional path shall be taken when a parameter to be passed 
to the scheduled task is specified in the HAL/SM construct. 
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Examples 


hi SCHEDULE IOTA; 


becomes 


L: DO; 


CALL RTL SCHED (BIN *0', IOTA); 


END; 

and 


SCHEDULE DELTA IN 30 SECS WHEN EVl & (EV2/EV3); 
becomes 

DO; 


TEMPORARY 

RTL_EVENT_VAR__UST NAME ARRAY (3) BIT (32), 
RTL_EVENT_EXP_STRING ARRAY (6) BIT (8); 

RTL_EVENT_VAR___UST. = EVl; 

RTL_EVENT_VAR_LIST2 = EV2; 

RTL_EVENT_VAR_LIST3 = EV3; 

RTL_EVENT_EXP_STRING, = HEX •01'; 
RTL_EVENT_EXP_STRING2 =HEX '02'; 
RTL__EVENT_EXP_STRING2 = HEX '03'; 
RTL_EVENT_EXP_STRING^ = HEX *4E'; 
RTL^EVENT^EXP^STRINGg = HEX '5C; 
RTL_EVENT_EXP_STR1NG^ = HEX '7E'; 

CALL RTL_SCHED (BIN 'oftlOO', DELTA, (30000)^ DOUBLE 

RTL_EVENT_VAR_LEST, RTL_EVENT_EXP_STRING, 3) 


END; 



3,1.22 WAIT Statement 
HAL/SM Syntax 
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where: 



1* This optional path shall be taken when an -<6 vent exp> appears 

in the HAL/SM construct. The path shall be repeated via a 
feedback loop as many times as there are event variables in. the 
event expression. The •<number>’ on this path shall be a one 
the first time through, and shall be incremented each time 
the path is taken for a given HAL/SM construct. Each <bit var>" 
on the path shall correspond to each of the <event var> s 
appearing in the HAL/SM construct, 

2, This optional path shall be taken when an <event exp> appears 
in the HAL/SM construct. The path shall be repeated via a 
feedback loop as many times as necessary to initiate the array 
with the Reverse Polish representation of the cevent exp>- (see 
Reference 3, Section 5,2,1). The cnumber> on this path shall 
be one the first time through, and shall be incremented each time 
the path is taken for a given HAL/SM construct, Each-<bit 
literals on the path shall correspond to the code for either an 
event operand or operator in the HAL/SM construct according 

to the conventions specified for MOSS event expressions, 

3, This <label>* shall be an entry point into the RTL to perform 
the required function, 

4, This <bit literal^ shall be a bit vector indicating the presence 
of certain optional parameters in the RTL invocation. 
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5* This <arith exp> shall correspond to the ctime value> in 
the FOR phrase of the HAL/SM construct, when present, 

6. This optional path shall be taken when an cevent exp>> appears 
in the HAL/SM construct. The <number> indicates the 
number of cevent var>- s present in the cevent exp>* . 

7, This optional path shall be taken when a THEN WAIT phrase 

appears in the HAL/SM construct. The <arith exp> corres- 
ponds to the value> in the HAL/SM construct. 

Examples 

STATES: WAIT FOR MET 50 SECS 25 MSECS 

UNTIL EVARI/EVARIO; 

becomes 

STATES: DO; 

TEMPORARY 

RTL_EVENT^VAR_LIST NAME ARRAY (2) 
BIT (S2), 

RTL_EVENT_EXP_STRING ARRAY (4) 

BIT (8); 

RTL_EVENT_VAR_LIST- = EVARl; 
RTL__EVENT_VAR_LIST2 = EVARl 0; 
RTL_EVENT_EXP_STRING. = HEX *01*; 
RTL_EVENT_EXP_STRING^ = HEX ’02'; 
RTL_EVENT_EXP_,STRING2 = HEX '4E'; 
RTL_EVENT EXP_STRING4 = HEX '7E»; 

CALL RTL_WAIT(BIN *01110', (50000)^^^^^^^ 

RTL_EVENT_VAR_UST, RTL_EVENT_EXP_ 
STRING); 

END; 


STATE4: WAIT FOR GMT 2 TSTART; 

becomes 


STATE 4: 


DO; 

CALL RTL_WAIT(BIN 'O', 2 TSTART); 

END; 
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Notes 


1 . This <label> shall be an entry point into the RTL to perform 
the required functions. 

2. This <bit var>“ shall correspond to the-<event var>- in the 
HA L/SM construct. 

3. This <bit literal^* shall indicate the presence of certain optional 
parameters in the RTL invocation. 

4. This *<label>- optionally specifies the HAL/S *<label>* corres- 
ponding to the task label, the program flag, or the ERP 
designator in the HA L/SM construct.. 

5. This optional path shall be taken when thecERP designator^ or 
< clocks is specified in the HAL/SM construct. The<number> 
shall correspond to the <relational op>, the IS BETWEEN, IS 
NOT BETWEEN, or the^, = specification in the HA L/SM con- 
struct. 

6. This optional path shall be taken when the <erp de signatory 
or <clock>- is specified in the HA L/SM construct. The carith 
exp> shall correspond to the <dim literals or <arith exp>* 
following the <erp designator^- or the<time valuO- following 
the <clock>- in the HAL/SM construct. 

Example s 

STATES: ALERT EVENT_VARl TO TERMINATION OF TASKAj 

becomes 

STATES: CALL RTL_ALERT (EVENT VARl, BIN »0‘, TASKA); 

and 


STATE?: 

becomes 

STATE?: 


ALERT EVENT VAR5 TO AI15 2 DELTA V; 


CALL RTL_ALERT (EVENT_VAR5, BIN 0AI15, 0, 

(2 
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3. 1.24 AVERAGE AI Statement 
HAL/SM Syntax 



Notes 


1 . This <label> shall be an entry point into the RTL to perform 
the required function. 

2. This <arith exp>- corresponds to the *<arith exp> which specifies 
the number of readings to be averaged in the HAL/SM construct. 
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3, This<label> shall specify the HA L/S <label> which corres 
ponds to the HAL/SM ^erp de signatory. 

4, This •<variable>' shall correspond to the ^variable^ which 
specifies the data storage area in the HAL/SM construct. 

Example 

STATElO: AVERAGE 2»N READINGS OF AINPUT_25 

ASSIGN A VERA.GE_VALUE; 

becomes 

STATElO: CALL RTL_A VERAGE(25rN, 0AI25) ASSIGN 

(A VER A GE_VA LUE) ; 
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3, 1*25 READ ERP Statement 










Notes 


1, This ^label^ shall be aix entry point into the RTL to perform 
the required function* 

2, This cnumber^ shall indicate the presence of the DELTAS option 
in the HAL/SM construct. 

3. This <number> shall specify the number of<label> s and 
< variable > s which follow^ 

4. This <label>' shall specify the HAL/S <label> which corresponds 
to the HAL/SM *<erp de signatory. 

5* This <variable> shall correspond to the < variable^ which 
specifies the data storage area in the HAL/SM construct. 

Example 

SENSE A INPUT -10 AND SAVE AS ALPHA; 
becomes 

CALL RTL_SENSE (0, 1, OAIlO, ALPHA); 
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3. 1.26 ISSUE Statement 


HAIj/SM Syntax 




Notes 

1. This dabel^ shall be an entry point into the RTL to perform 
the required functions. 

2. This dabel> shall specify the HA L/S <label>- which corres- 
ponds to the HAL/SMcerp designator^. 
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Example 

STATEl: 

becomes 

STATEl: 


ISSUE B21, B32 TO RECORD__23; 


CALLRTL ISSUE (0R23, B21, B23); 
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3*1.27 SET Discrete Statement 


HAL/SM Syntax 












Notes 


1. This -<label>- shall be an entry point into the RTL to perform 
the required function, 

2. This <number>’ shall specify the number of dabel>- s to follow. 

3. This <label>“ shall specify the HAL/S <label>* which corres- 
ponds to the HAL/SM cerp designators. 

4. This <numbers shall specify the number of values to follow, 

5. This*^arith exp> shall correspond to the<time values in the 
FOR phrase of the HAL/SM construct, when present. 

Example 

STATES: SET DOH, DOl2 TO 10, 12 FOR DELTAT; 

becomes 

STATES: CALL RTL_SETD(2, ODOll, 0DO12, 2, 10, 12, 
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3.1.Z8 APPLY Analog Statement 










Notes 


1, This -<label>- shall be an entry point into the RTL to perform 
the required function. 

2, This '<number>' shall indicate the presence of the DELTAS, 
RAMPED TO, or pulsed options. 

3, This <number> shall specify the number of <arith exp> s 
and <label> pairs to follow. 

4, This <arith exp> shall specify the value or values to be 
APPLYed to the <erp de signatory. 

5, This ^label^" shall specify the HAL/S <label> which corres- 
ponds to the HAL/SM -<erp de signatory. 

6, This optional path shall be taken when the value(s) is to be pulsed 
or ramped. The <arith exp> shall correspond to the*<time 
value>* in the FOR phrase of the HAL/SM construct. 

7, This <arith exp>- shall correspond to the cdim literal^ or 

c arith exp> following RAMPED TO or UNTIL in the HAL/SM 
construct. 

Example 

STATE25: APPLY DELTAV TO A024 FOR 2 TSTART UNTIL MAXV; 

becomes 

STATE25: CALL RTL APPLY (1 , 1, (DELTA V), OA 024, (2 TSTART) 

©double' 
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3.1.29 DISPLAY TO OPERATOR Statement 
HAL/SM Syntax 




1. This clabel^ shall be an entry point into the RTL to perform 
the required function. 

2. This optional path shall be taken when ACCEPT REPLY IN 
appears in HAL/SM construct. 
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Example 

MESSl: 

becomes 

MESSl: 


DISPLAY TO OPERATOR ’HAS JO BA BEEN INITIATED’, 
ACCEPT REPLY IN REPLY BUFFER; 


CALL RTL_WTOR (’HAS JOBA BEEN INITIATED', 

REPLY BUFFER); 
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3. 1. 30 DISPIJ^Y CONTROL Statement 
HA L/SM Syntax 








Notes 


1, This clabel^ shall be an entry point in the RTL to perform 
the required function, 

2, This cnumber^ shall indicate which control function is to be 
performed, 

3, Thiscbit literal> shall indicate the presence of the optional 
RTL CRT parameters, 

4, This optional path shall be taken when the TO ^CRT •< number > 
<number>>*is specified in the HAL/SM construct. 

Example 

CONTROLl: VIDE02 STROKE TO <CRT1 -4> ; 

becomes 

CONTROLl: CALL RTLJDISCON(6, BIN 1,4); 
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HAJj/S Code Template 






Notes 


I. This ^label^* shall be an entry point into the RTL to perform 
the required functions* 

Z, This optional path shall be taken when DISPLAY BGROUND or 
DiSPliA Y ADDON are specified in the HAL/SM construct, 

3. This <identifier2> shall specify the program label by which 
the BACKGROUND and ADDON disk messages are identified. 

4, This <number>' shall identify the record within the data set 
specified by note 2 that contains the BACKGROUND or ADDON 
message, 

5, This cbit literal > shall specify the presence of the BUNK STATUS 
option in the HAL/SM construct, 

6, This <number> shall specify the number of <variable> and 
associated <dcw var> pairs in the DISPLAY BGROUND and 
DISPLAY ADDON options of the HAL/SM construct, 

7. This <bit var> shall correspond to the <dcw var>* following 
the WIDTH <number> specification in the HAL/SM construct. 

8. This <variable> corresponds to the cvariables*- following the 
FOR in the HAL/SM construct, 

9* This <bit literals shall specify the presence of the cCRT 

<number<:- <number«: specification in the HAL/SM construct. 

10, This optional path is taken when cCRT <number> - <:number> > 
is specified in the HAL/SM construct. 

II, This optional path is taken when the DISPLAY cidentifier > or 
UPDATE cidentifier^is specified in the HAL/SM construct. 

12, This cchar literal> corresponds to the < identifier > s mentioned 
in note 11. 

13, This cnumber^ shall specify the number of < variable > s in the 
UPDATE <identifier>’ option of the HAL/SM construct. 
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14 


This optional path shall, correspond to the UPDATE -<identifier> 
option in the HAL/SM construct. The < variable > shall corres- 
pond to the *<variable> after ^identifiers in the HAL/SM con- 
struct. 


15. This optional path shall correspond to the UPDATE < labels in 
the HAL/SM construct. 

Example s 

STATEl: DISPLAY ADDON TO <CRT 1 - 4SBLENK STATUS 

TEXTCWl TEXT 'THIS IS SAMPLE DATA', 
WIDTH 10 VARCWl FOR DATA_ARRAY; 

becomes 

STATEl: CALL RTL_DISADD(PROGl, 10, BIN '!', 1, VARCWl, 

DATA_ARRAY, BIN '!', 1, 4); 

and 

STATES: DISPLAY BGROUND LINE 3 COL 10 TEXTCWl TEXT 

'THE ALTITUDE VARIATIONS ARE', UNE 5 COL 
15 WIDTH 3 VARCW2 FOR ALTITUDE; 

becomes 

STATES; CALL RTLJDISBACK(PROGl , 15, BIN 'O', BIN '0'); 


and 

STATEIO: UPDATE STATES; 

becomes 

STATEIO: CALL RTL_DISUPD(1, VARCW2, ALTITUDE, BIN 'O', 

BIN '0'); 
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3.1»32 Modify VCW Statement 
HALt/SM Syntax 




1* This cbit var> shall be the HAL/S variable corresponding to the 
<dcw var>*inthe HAL/SM construct, 

2* This <bit var>- shall be the HAL/S variable corresponding to the 
<dcw var>* in the HAL/SM construct with added component sub- 
scripting to select a specific bit field within the variable, 

3, This < bit liter al^ shall be an encoded value specifying one or 

more of the dew options specified to be modified by the <dcw 
value list^* of the HAL/SM construct. 

Example 

MODIFY DCW_1 = BUNK ONj 
becomes 

DCW_1 = DCW_lo IIBIN U' ||DCW_1^^ TO 31; • 
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3.1.33 REQUEST Keyboard Statement 
HAL/SM Syntax 



HAL/S Code Template 



This clabel> shall be an entry point into the RTL to perform 
the required function. 

This cchar var> shall be the same as the corresponding character 
variable in the HAL/SM construct. 

This -<bit var>* shall be the same as the corresponding bit 
variable in the HAL/SM construct, when present. 
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Example 

REQUEST ENTRY FROM<KEYBOARD>AND SAVE AS RESPONSE 
becomes 

CALL RTL_RQST_KYBD(RESPONSE); 
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3. 1. 34 SELECT Statement 


HA L/SM Syntax 
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HAL/S Code Template 



1. This ”<label>’ shall be an entry point into the RTL to perform 
the required function* 

2* This < labels shall correspond to the DATA or PROGRAM 

module label specified in the HAL/SM construct, when present. 

3. This <number> shall correspond to the SPIOS I/O channel 

or file number specified in the HALt/SM construct, when pre- 
sent* The range of values shall distinguish between channels 
and files, 

4* This<bit literal^ shall indicate the access rights specified 

in the HAL/SM construct for each resource. The format is the 
same as the parameter list entry 2 for the SELECT SVC inter- 
face to MOSS (see Reference 7, Section 5,5.1), 

Example 

SELECT DSD CHANNEL (6) WRITE, DISP = LEAVE; 
becomes 

CALL RTL_SELECT (-6, HEX' 0201 01 02'); 


-T?-' 





3. 1, 35 RELEASE Statement 


HAL/SM Syntax 



HAL/S Code Template 



1. This ^label^ sl^ll be an entry point into the RTL to perform 
the required function. 


2* This <number>* shall correspond to the SPIOS I/O, channel 

or file number specified in the HAL/SM construct. 

3, This *<label> shall correspond to the resource label specified 

in the HAL/SM construct. 
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Example 


RELEASE DATAMOD, CHANNEL (3); 
■becomes 

CALL RTL__RLSE (DATAMOD, -3); 
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3,1,36 CHANNEL Control Statement 



HAL/S Code Template 
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Notes 


1, This '<label> shall be an entry point into the RTL to perform 
the required function. 

2. This < number >* shall be the channel number of the SPIOS I/O 
channel being manipulated* 

3* This ^number^* shall indicate the function to be performed. 

4. This <arith exp> shall correspond to the *<arith exp> in the 
HALt/SM construct, when present, and shall have a value of 
one, otherwise. 

Example 

L; CHANNEL (3) SPACE N_FILES + 1; 
becomes 


L; CALL RTL CHAN (3, 2, N_FILES+1); 



3.1.37 CRITICAL SECTION 



HAL/S Code Template 



















Notes 


I, This <:label> shall be a symbol generated by the preprocessor 

to identify the nested procedure. This procedure is an artifice to 
force the compiler to enter a new name scope* 

2* This <label> shall be an entry point into the RTL to cause 
the task to enter critical mode, 

3* This '<label> shall be an entry point into the RTL to cause the 
task to exit from critical mode. 

Example 

DO_IT: CRITICAL SECTION; 

CALL DOJ[T_FAST; 

CLOSE; 

becomes 

DO_IT: DO; 

GOOOOOl: PROCEDURE; 

CALL RTL_GO_CRITICAL; 

CALL DO_IT__FAST; 

CALL RTL_STOP__CRITICAL; 

CLOSE; 

CALL GOOOOOl; 


END; 
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HAL/S Code Template 



Note 

1* The preprocessor shall convert ctime literals s to acnumber^ 
indicating the required time in milliseconds. 


30 SECS 
becomes 

2'’°°°@D0UBLE -84- 






3,1.39 EVENT Variable 
HAL/SM Syntax 


/bit \ 

\operand / 

— (^NOT ^ — 




event var — ■ — — 



HAL/S Code Template 



1, This < labels* shall be an entry point into the RTL to return as 
its value the value of the specified HAL/SM < event var>, 

2, This <bit var>* shall be the HAL/S variable corresponding to 
the HAL/SM "^event var>. 
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3,1,40 OPEN and CLOSE Literals 


HAL/SM Syntax 


Ait \ 

\ literal / 

^ OPEN ^ 


v/ ^ * 




HAL/S Code Template 



1, The <bit literal definition^ shall be inserted in a COMPOOL 

template at the beginning of each HAL/S source module produced 
by the preprocessor. 
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3.2 


HALLINK 


This subsection discusses the differences between the HAL/SM and 
the HAL/S-360 HA BUNK programs. The following modifications shall be 
made to the HALLINK and HALLKED modules of the HALLINK program: 

o Force the suppression of the HALMAP CSECT in the 

output load module. . 

o Verify that the flight computer timing simulation ”cost- 

use” arrays have been suppressed during compilation. 

o Verify that there are no nested HAL/S TASK*s in the 

output load module. 
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3.3 


RTL 


This subsection enumerates the new and modified modules in the 
HAL/SM RTL. Each numbered paragraph discusses a single RTL interface 
or functional module and describes its characteristics in terms of calling 
sequence, parameter lists, standard linkage conventions (see Reference 4), 
function, and/or MOSS interface. For new modules (i. e. , those not in the 
HAL/S-360 RTL) all of the above mentioned facets are discussed (where they 
are pertinent). For modified modules only those facets of the module which 
require modification are discussed. 
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3, 3. 1 ON ERROR Interface 


The ON ERROR routines shall be additions to the RTL. 

Calling Sequence (Fornnl) 

CALL RTL_ON_ERROR1(Pj,P2»P3»P4); 

Parameter Lisjb 

error group number* 
error number within the group, 
the error action indicator specified as; 

0 - SYSTEM, take the standard recovery action, 

1 - IGNORE, do not attempt recovery, 
the flag variable to be signaled on occurrence of the error. 

Linkage Convention 

Normal HAL/S-360 linkage. 

Function 


Pj:- 

Pz' 

P3! 


P 4 : 


The RTL ON ERROR (Form 1) routine shall establish the error infor- 
mation specified in the parameter list in this program's error environment 
stack. The error information shall be used by the error monitor to determine 
the actions to take when an error occurs. 

Calling Sequence (Form 2) 

CALL RTL_ON__ERROR2(p^,P2,P3); 

Parameter List 

pj! error group number, 

p^; error number within the group. 

P 3 ; address (label) of the statement to be executed when the 
error occurs. 
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Linkajge Convention 


Normal HAL/S-360 linkage* 

Function 

The RTL ON ERROR routine (Form 2) shall establish the error infor- 
mation specified in the parameter list in this program's error environment 
stack* The error information shall be used by the error monitor to determine 
the actions to take when an error occurs. 
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3,3,2 OFF ERROR Interface 


The OFF ERROR routine shall be an addition to the RTL, 
Calling Sequence 

CALL RTL_OFF_ERROR(Pj,P 2); 
parameter List 


Pjt ^ error group number, 

p^: error number within the group. 

Linkage Convention 

Normal HAL/S-360 linkage. 

Function 


The RTL OFF ERROR routine shall establish the error information 
specified in the parameter list in the program's error environment stack. 
The error information shall be used by the error monitor to determine the 
actions to be taken when an error occurs. 
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3. 3. 3 SIGNAL. Interface 


This RTL routine shall replace the current HAL/S signal routine; 
Calling Sequence 

CALL RTLJ5IGNAL(Pj,P2,..,,P^); 

Parameter List 


Each parameter in the list shall be the same type* The parameter 
specification shall be repeated as required, 

pj : the flag variable to be signaled. 

Linkage Convention 

NONHAL(l) linkage. 

Function 

The RTL SIGNAL routine shall set up the parameter list for the MOSS 
event set interface (see Reference 7, Section 5.3.4) and issue the SVC 
instruction to invoke that service. 


C ^ 
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3.3.4 RESET Interface 

This RTL routine shall replace the current HAL/S reset routine. 
Calling Sequence 

CALL RTL RESET^p,,p,,..., p ); 

Parameter List 


Each parameter in the list shall be the same type. The parameter 
specification shall be repeated as required. 

Pj: the event variable to be reset. 

Linkage Convention 

NONHAL(l) linkage. 

Function 

The RTL RESET routine shall up the parameter list for the MOSS 
evei^t delete interface (see Reference 7, Section 5,3,2) and issue the SVC 
instruction to invoke that service. 
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3.3,5 CANCEL Interface 


This RTL routine shall replace the current HAL/S CANCEL routine. 

No new syntax has been added to support the CANCEL interface, however, the 
function has changed. 

Calling Sequence 

CALL RTL_CANCEL(Pj); 

Parameter .List 

Pj: the task descriptor of the task to be canceled. This parameter 

shall be optional; if omitted, the requesting task shall be 
canceled. 

Linkage Convention 

NONHAL(l) linkage. 

Function 

The RTL CANCEL routine shall set up the parameter list for the MOSS 
task CANCEL interface (see Reference 7, Section 5.2. 6) and issue the SVC 
instruction to invoke that service. 

Upon return from MOSS, the return, code shall be examined for the 
two abnormal conditions; 

o the specified task was not in the proper state, and 

o the specified task was not periodic and was already in 

execution, 

HAL/S run time errors shall be generated corresponding to the type of error 
encountered. 
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3. 3, 6 TERMINATE Interface 


This RTLi interface shall replace the current HAL/S TERMINATE process 
routines - TERMIN, TERMINT, TERMPCB. The TERMINATE statement shall 
invoke either the TERMINATE TASK or the TERMINATE JOB routine as 
described below. 

Calling Sequence (TERMINATE TASK) 

CALL RTL__TTERM; 

Linkage Convention 

Normal HAL/S-360 linkage. 

Function 


The RTL TASK TERMINATE routine shall invoke the MOSS 
TERMINATE interface (see Reference 7, Section 5,2.3) via an SVC instruc- 
tion. 

Calling Sequence (TERMINATE JOB) 

CALL RTL_JTERM; 

Linkage Convention 

Normal HAL/S-360 linkage. 

Function 

The RTL JOB TERMINATE routine shall invoke the MOSS JOB TER- 
MINATE interface (see Reference 7, Section 5, 1.3) via an SVC instruction. 


- 95 - 



3.3.7 A BORT Interface 

The ABORT interface shall invoke either the ABORT job or the ABORT 
task routine described below. These routines are additions to the RTL. 

Calling Sequence (ABORT JOB) 

CALL RTL_JABORT; 

Linkage Convention 

NONHA L (1) linkage. 

Function 


The RTL job ABORT routine shall invoke the MOSS job ABORT interface 
(see Reference 7, Section 5.1.4) via an SVC instruction. 

Calling Sequence (ABORT TASK) 

CALL RTL^TABORT (pj, p^); 

Parameter List 

Each parameter in the list shall be the same type. The parameter 
specification shall be repeated as required. 

Pj: the task descriptor of the task to be aborted. This parameter 

shall be optional; if omitted, the requesting task shall be 
aborted. 

Linkage Convention 

Normal HAL/S-360 Hnkage. 

Function 


The RTL task ABORT routine, shall set up the parameter list (if any) 
for the MOSS task ABORT interface (see Reference 7, Section 5.2,4) and 
issue the SVC instruction to invoke that service. 
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3, 3, 8 LOG Interface 


The LOG routine is an addition to the RTL. 
Calling Sequence 

CALL RTL_LOG (p^); 

Parameter list 


pj: the character expression to be written to the MOSS system log* 

Linkage Convention 

Normal HAL/S-360 linkage. 

Function 

The RTL LOG routine shall set up the parameter list for the MOSS 
write to log interface (see Reference 7, Section 5, 4.4) and issue the SVC 
instruction to invoke that service. 

Upon return to MOSS, the return code shall be examined to determine 
if the message exceeded 126 bytes. If so, a HAL/S run time error shall be 
generated within the library. 
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3,3,9 UNLOCK Interface 

The UNLOCK routine is an addition to the RTL, 

Calling Sequence 

CALL RTL UNLOCK (p,, p_, p ); 

i i n 

Parameter List 

Each parameter in the Hst shall be the same type. The parameter 
specification shall be repeated as required, 

Pj : the load module descriptor that identifies the module to 

be unlocked. 

Linkage Convention 

NONHAL (1) linkage. 

Function 


The RTL UNLOCK routine shall set up to the parameter list for the 
MOSS UNLOCK interface (see Reference 7, Section 5, 4, 2) and issue the 
SVC instruction to invoke that service. 
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3« 3. 10 LOAD Interface 


The LOAD routine is an addition to the RTL. 

Calling Sequence 

CALL RTL_LOAD (p^); 

Parameter List 

' the job descriptor of the job to be loaded. 

Linkage Convention 

NONHA L (1) linkage. 

Function 

The RTL job LOAD routine shall set up the parameter list for the 
MOSS job LOAD interface (see Reference 7, Section 5. 1.1) and issue the SVC 
instruction to invoke that service. 

Upon return from MOSS, the return code shall be examined to 
determine if either of the following abnormal conditions occurred; 

o the job descriptor was invalid, or 

o the job was not in the proper state for loading. 

If either of these conditions is present, the appropriate run time error shall 
be generated within the library. 
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3, 3. 11 INITIATE Interface 

The INITIATE routine is an addition to the RTL, 
Calling Sequence 

CALL RTL_INIT (pj); 

Parameter List 


the job descriptor of the job to be initiated. 

Linkage Convention 

NONHA L (1) linkage. 

Function 

The RTL job INITIATE routine shall set up the parameter list for the 
MOSS job INITIATE interface (see Reference 7, Section 5.1,2) and issue the 
SVC instruction to invoke that service. 

Upon return from MOSS, the return code shall be examined to deter- 
mine if the following conditions occurred: 

o the specified job was not in External Paging Memory 

(EPM), or 

o the specified job was not in the proper state for job 

initiation. 


If either of these conditions is present, the appropriate run time error shall 
be generated within the library. 
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3, 3, 12 DELETE Interface 

The DELETE interface shall invoke either the DELETE job or DELETE 
task routines described below. These routines are additions to the RTL, 

Calling Sequence (JOB DELETE) 

CALL RTL_JDEL; 

Linkage Convention 

Normal HAL/S-360 linkage. 

Function 


The RTL job DELETE routine shall invoke, the MOSS job DELETE 
interface (see Reference 7, Section 5, 1.5) via an SVC instruction. 

CalHng Sequence (TASK DELETE) 

CALL RTL_TDEL; 

Linkage Convention 

Normal HAL/S-360 Linkage. 

Function 

The RTL task DELETE routine shall invoke the MOSS task DELETE 
interface (see Reference 7, Section 5.2.5) via an SVC instruction. 
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3. 3. 13 SCHEDULE Interface 


This RTL routine shall replace the current HAL/S SCHEDULE routine. 
Calling Sequence 

CALL RTL_SCHEDULE (pj, p^, p^, P 7 ' Pg' ^9^* 

Parameter List 

Pji - a bit vector indicating the presence and format of the optional 
parameters p 3 ~p • The format of the bit vector and the 
meaning of a ’’one" in the corresponding position in the vector 
are; 


Bit Number 
0 

1.2 


3 

4 


Meaning 

p^» the schedule parameter is present. 

A 2 -bit value indicating the presence and 
format of p^, the precondition time delay 
as follows; 

0 - not present 

1 “ millisecond time interval delay 

2 - GMT time value delay 

3 - MET time value delay 

pg, p^, p^; the event expression parameters 
are present. 

Pg, the time interval delay after events are 
considered parameter is present. 


5 pg, the repetition time delay for cyclic tasks 

is present. 

p : the task descriptor of the task being scheduled. 

pg*. the character schedule parameter to be passed to the task 
being scheduled. 


p^: the time delay to be applied before considering any of the other 

conditional scheduling parameters. The time delay value may 
be a millisecond time interval, a GMT time value, or a MET 
time value as indicated by p^. 
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P6 



an array of event variables whose logical combination, as 
indicated by must be satisfied before the task is scheduled. 


an array of logical operators defining the logical expression 
of event variables as given in Pg. The event expression shall 
be represented in Reverse Polish form. 

the number of event variables in the array given in pg. 


Pg; the millisecond time value which must expire after the event 
e3q>ression is satisfied before the task is scheduled. 

p^; the millisecond time period between successive scheduling for 
a periodic task. 


Linkage Convention 

NONHA L (1) linkage. 
Function 


The RTL SCHEDULE routine shall set up the parameter list as received 
in the format required by the MOSS task SCHEDULE interface (see Reference 
7, Section 5.2. 1) and issue the SVC instruction to invoke that service. 

Upon return from MOSS, the return code shall be examined to deter- 
mine if the parameter data was too large for the receiving task. If so, a 
HAL/S run time error shall b© generated within the library. 
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3.3,14 WAIT Interface 


The WAIT routine shall replace the current HAL/S WAIT routine - WAIT, 
WAITDEP, and WAITFOR. 

Calling Sequence 

CALL RTLJVAIT (pj, p^, p^, p^, p^) 

Parameter List 

Pj*. a bit variable indicating the presence and format of the optional 
parameters P 2 "P 6 * The meaning of each bit position is given 
below: 

Bit Number Meaning 

0, 1 A 2-bit value indicating the presence and 

format of the precondition time delay, 

0 - time delay not given 

1 - time delay given for milliseconds time 

interval 

2 - time delay given for GMT time value 

3 - time delay given for MET time value 

2 An event expression (p^, p^, and p^) is 
present, 

3 A post -condition time interval delay in 
milliseconds is present, 

p^: the time value to delay before considering any other WAIT 

conditions. The format of this value shall be indicated by p^, 

p^: an array of event variables whose logical combination, as 

indicated by p^, must be satisfied before the task continues, 

p^: an array of logical operators defining the logical expression of 

event variables given in p^. The event expression shall be re- 
presented in Reverse Polish form. 

p ; the number of event variables in the array given in p*. 
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p^: the millisecond time value which must expire after the event 

expression is satisfied before the task is allowed to continue. 

Linkage Convention 

NONHAL (1) linkage. 

Function 


The RTL WAIT routine shall set up the parameter list for the MOSS task 
SUSPEND interface (see Reference 7, Section 5,2.2) and issue the SVC instruc- 
tion to invoke that service. 
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3, 3, 15 AIjERT Interface 

The ALERT routine is an addition to the RTL. 

Calling Sequence 

CALL RTL_ALERT (p^, p^, P^, P^, Pg, P^) 

Paranneter List 

p. : the bit variable corresponding to the HAL /SM event variable 

to be ALERTed, 

p^: a bit vector indicating presence and format of the optional 

parameters p 3 "Pg‘ The meaning of each bit position is given 
below: 




Bit Number Meaning 

0,1,2 A 3-bit value indicating the presence and 

format of p^, the event descriptor. 

0 - event is task termination; P^ is present. 

1 - event is a program flag; p^ present. 

2 - event is an ERP condition; p^ and p^ 

are present, 

4 - event is a MET clock condition; P^ is 

absent, p 4 and p^ are present, 

5 - event is GMT clock condition; p^ is 

absent, p^ and p^ are present, 

the event descriptor specified as a task descriptor, flag 
variable, or an ERP descriptor* 

a number giving the relational operators for ERP and clock 
events* The values of this parameter are given in Reference 7, 
Section 5,3, 1, When this parameter indicates an ”is between” 
or "is not between" relation, p^ is present, 

the value to which the ERP or clock specified is to be compared, 
as indicated by the relation given in p^. 

the second value to be used in the comparisons "is (not) between, " 
as indicated by p^* 
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Linkage Convention 


NONHA L (1) linkage. 
Function 


The RTL AI^RT routine shall set up the parameter list for the MOSS 
event ALERT interface (see Reference 7, Section 5,3, 1) and issue the SVC 
instruction to invoke that service. 
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3»3,16 AVERAGE Interface 


The AVERAGE A I routine is an addition to the RTL, 
Calling Sequence 

CALL RTL_A VERA GE (p^, p^) 

Para meter List 

the number of readings to be averaged, 
the ERP designator to be averaged, 
the variable in which the result is to be stored. 
Linkage Convention 

Normal HAL/S- 360 linkage. 

Function 



The RTL AVERAGE AI routine shall set up the parameter list for the 
MOSS read ERP interface (see Reference 7, Section 5,6.2), The parameter 
list shall indicate the read AI A VERAGEd option and the address of the RTL’s 
I/O error processing routine. 
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3* 3, 17 READ ERP Interface 


The READ ERP routine is an addition to the RTL* 
Calling Sequence 

CALL RTL_SENSE (p^, p^, p^/ - ..i 


Parameter List 


P,: 


Pz* 


p^“P : 
3 *^n 


^n+1 Pm* 


a number whose value indicates the presence of the 
READ AI deltas option as follows: 

0 - AI deltas option not requested, 

1 - Al deltas option requested, 

a number whose value indicates the number of ERP's 
to be read. 

each of these parameters shall be an ERP designator 
to be read. All of the ERP’s given must be of the same 
type, 

each of these parameters shall be a variable in which 
the results of the READ operation for each of the ERP 
designators in p 2 ^"Pj^ is to be placed. The number of 
parameters in tms group shall be the same as in the 
grouppg-p^* 


Linkage Convention 

NONHA L (1) linkage. 
Function 


The RTL READ ERP routine shall set up the parameter list for the 
MOSS READ ERP interface (see Reference 7, Section 5, 6,2) and invoke that 
service via an SVC* The parameter list shall be paired for each ERP designa 
tor and corresponding variable data area. The address of the RTL's I/O 
error processing routine shall be included as a parameter for each ERP 
designator. 
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3, 3* 18 ISSUE Interface 

The ISSUE routine is an addition to the RTL. 

Calling Sequence 

CALL RTL ISSUE (p,, p ) 

1 4 n 

the RO ERP designator to which the issue applies* 
each of these parameters shall be the same t 5 rpe - either 
o variables of the same type, 

o bit literals, or 

o numbers. 

The collection of parameters P 2 *P shall form the data 
to be issued to the RO. ^ 


Parameter List 

Pi=' 

P2'P«= 


Linkage Convention 

NONHA L (1) linkage. 

Function 

The RTL ISSUE routine shall collect the data in each of the input para- 
meters p^-pn and form a contiguous data area. The address of this data 
area, its length, the ERP designator, and the address of the RTL's I/O error 
processing routine shall be passed in a parameter list to the MOSS WRITE 
ERP interface (see Reference 7, Section 5.6,3) via an SVC instruction. 
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3. 3. 19 SET DISCRETE Interface 

The SET DISCRETE routine is an addition to the RTD, 
Calling Sequence 


CALL RTL__SETD (p^. 




a+l' Pr+Z' 






Paramete r Li st 


Pr 

Pz-Pn’' 

Pn+r 

Ph+2’Pm* 


this parameter shall specify the number of DO ERP 
descriptors to follow, 

each parameter shall be of the same type, DO ERP 
descriptor, and shall indicate the discretes to be set, 

this parameter shall specify the number of value para- 
meters to follow, 

each parameter shall be of the same type, either: 
o variable of the same type, 

o bit literals, or 

o numbers. 


P 


m+1 ■ 


Each parameter gives the value to set to the correspond- 
ing DO defined in 


the time value in milliseconds that the DO is to be pulsed. 
This parameter is only allowable when p^ and p 
specify a single DO to be pulsed. 


11+2 


Linkage Convention 


NONHA L (1) linkage. 


Function 


The RTL SET DISCRETE routine shall pair each DO ERP designator 
and its corresponding value in a parameter list for the MOSS WRITE ERP 
interface (see Reference 7, Section 5,6,3), If a single DO to be pulsed is 
specified, the parameter list shall include the time value parameter. The 
address of the RTL’s I/O error processing routine shall be included as a para- 
meter for all requests. The WRITE ERP service shall be invoked via an SVC 
instruction when the parameter list is complete. 
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3. 3.20 APPLY ANALOG Interface 

The APPLY ANALOG routine is an addition to the RTL. Multiple form 
of the calling sequence and parameter list are shown to simplify the explana- 
tions due to special cases which may be generated. 

Calling Sequence (APPLY ANALOG - DELTAS) 

CALL RTL__APPLY (p^, p^, p^, p^) 

Parameter -List 


pjt an indicator which specifies the special option selected, 
1 - DELTAS 


^ 2 ~^ 3 * values to be applied as deltas, 

p^: the AI ERP designator to which the delta values given 

in p^ and p^ are to be applied, 

CalUng Sequence (APPLY ANALOG - PULSED) 

CALLRTL^APPLY (p^, p^, P 3 , p^) 

Parameter List 


pjt special option indicator: 
2 - PULSED 


p^: the value to be applied to the AO, 

p^: the AO ERP designator to be pulsed, 

p^; the time value indicating the length of the pulse. 
Calling Sequence (APPLY ANALOG - RAMPED) 

, CALL RTL^APPLY (pj, p^, P 3 , p^, Pg) 

Parameter List 

p^: special option indicator: 


3 - RAMPED 
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p the initial value to be applied to the AO. 

p^; the AO ERP designator to be ramped, 

p^: the time value for each increment of the ramp. 

p^; . the maximum (or minimum for negative ramping) to 
which the AO is to be ramped. 

Calling Sequence (APPLY ANALOG No Special Options) 

CALL RTL_APPLY (p^^ p^, p^, . , . , p^, P^+l' ” * ' ^m^ 

special option indicator: 

0 ~ no special options 

the number of multiple ERP designators being supplied, 

each parameter of this group shall be the value to be 
applied to the AO's specified in parameters p , , -p . 

each parameter of this group shall be an AO ERP 
designator to be applied. 

Linkage Convention 

NONHA L (1) Unkage. 

Function 


Parameter List 


Pr 


P2' 


p^-p •• 


Pn+1-P~ = 


m 


The RTL APPLY ANALOG routine shall set the parameter list as 
indicated for each of the cases given above for the MOSS WRITE ERP interface 
(see Reference 7, Section 5,6.3). The address of the RTL's I/O error pro- 
cessing routine shall be included in the parameter list. The WRITE ERP 
interface shall be invoked via an SVC instruction. 
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3.3.21 WRITE TO OPERATOR Interface 

The WRITE TO OPERATOR routine is an addition to the RTL. 

Calling Sequence 

CALL RTL_WTO (p^, p^, p^) 

Par ameter List 

a bit variable indicating whether the reply option has 
been selected: 

0 - no reply, p, is present. 

1 - reply expected, p is present. 

the character expression to be displayed to the operator, 
the character variable in which any reply is to be stored. 
Linkage Convention 

NONHA L (1) linkage. 

Function 

The RTL WRITE TO OPERATOR routine shall examine p^^ to determine 
if the reply option has been selected. If no, p^ and its length shall be passed 
to the MOSS WRITE TO OPERATOR interface (see Reference 7, Section 5 4,5) 
via an SVC instruction. If the reply option has been selected, p , its length, 
and p shall be passed to the MOSS WRITE TO OPERATOR withlREPLY inter- 
face (see Reference 7, Section 5.4.6), 

A runtime error shall be generated if the output message exceeds 100 
bytes for either case. 
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3, 3.22 DISPLAY CONTROL Interface 

The DISPLAY CONTROL routine is an addition to the RTL, 

Calling Sequence 

CALL RTL^DISCON (p^, p^, P3, p^) 

Parameter List 

pj: the control function indicator whose value shall be 

interpreted as follows; 

0 - page select 

1 - clear page 

2 - video 1 

3 - video 1 /stroke 

4 ^ video 2 

5 - video 2/stroke 

6 - allocate page 

7 - deallocate page 

p^: a bit vector whose value shall indicate the presence of 

p^ and p^, the CRT, and page number. 

0 - p^ and p^ are absent 

1 - p^ and p^ are present 

p^: the CRT number to which the control function shall be 

directed. 

p^; the page number to which the control function shall be 
directed. 

Linkage Convention 

NONHA L (1) linkage. 

Function 

The RTL DISPLAY CONTROL routine shall examine the control function 
indicator, pj. If the allocate or deallocate page functions have been selected. 
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the MOSS allocate or deallocate console page interface shall be invoked with 
the CRT and page number parameters. To perform the other functions^ MOSS 
DISPLiAY CONTROL interfaces shall be invoke the appropriate parameters. 
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3.3.23 DISPLA Y DATA Interface 

The DISPLAY DATA interface shall invoke either the DISPLAY BACK- 
GROUND, DISPLAY ADDON, UPDATE BACKGROUND, DISPLAY TYPEl 
PROGRAM, or UPDATE TYPE! DATA routines described below. These 
routines are additions to the RTL. 

Calling Sequence (DISPLAY BACKGROUND) 

CALL R TL__DISBA CKD (Pj, ^2* ^3^ ^4^ ^5* ^6^ 

Parameter List 

pj : the program identifier by which the data set containing 

the background message is identified. 

p^: the message identification number which specifies the 

record number of the message within the data set. 

p^: the blink status option specification. 

p^: the bit indicator which indicates the CRT number and 

page number to follow, 

p^: the CRT number (if specified), 

p^: the page number (if specified). 

Linkage Convention 

NONHA L (1) linkage. 

Function 


The RTL DISPLAY BACKGROUND routine shall set up the parameter 
list for the MOSS DISPLAY BACKGROUND (from disk) interface and issue 
the DISBACKD SVC. (This SVC obtains the indicated message from the C&D 
message library and transmits it to the indicated C&D Console page, ) 

An l/O ERROR EXIT routine shall be provided in the RTL routine and the 
entry point to this code shall be provided in the SVC parameter list. 
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Calliag Sequence (DISPLA Y ADDON) 

CALL RTL_DISADD (p^, p^, p^, p^, p^, p., p., p^, p^); 

Parameter List 


Pj : the program identifier by which the data set containing 

the ADDON message is identified. 

p^: the message identification number which specifies the 

record number of the message within the data set. 

p : the blink status option specification. 

3 

p^; the numbers of pairs, each containing a variable control 
word and an associated variable used to describe the 
ADDON variable data. 

^5**^i* ^ “ "^+2*p^): the pairs of variable control word with 

associated variable described above. The sequence is: 
variable control word, variable, variable control word, 
variable, ... 

p.: (where j = i+1); the bit indicator which indicates that a 

^ CRT number and page number follow. 

pj^; (where k = i+2); the CRT number (if specified). 

^m* (where m = i+3): the page number (if specified). 

Linkage Convention 

NONHA L (1) linkage. 

Function 

The RTL DISPLAY ADDON routine shall convert any variable data to 
ASCII format, set up the parameter list for the MOSS DISPLAY ADDON (from 
disk) interface, and issue the DISADD SVC. (This SVC obtains the indicated 
ADDON message from the C&D message library, updates any variable fields 
specified, and transmits it to the indicated C&D Console page, ) 

An I/O ERROR EXIT routine shall be provided in this RTL routine and 
an entry point to this code shall be provided in the SVC parameter list. 
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Callitig Sequence (UPDATE BACKGROUISID) 

CALL RTL UPDISM(p-, Po» • • • » P- » P-> Pi # P » P ) 

Parameter List 

Pji the number of pairs, each containing a variable control 
word and an associated variable to be updated. 

^2"^i* ^ ~ Z+E^p^): the pairs of variable control word and 

associated variable described above. The sequence shall 
be variable control word, variable, variable control word, 
variable, ... 

py (where j = i+1): the blink status option specification. 

pj^; (where k = i+2): the bit indicator which indicates that a 

CRT number and page number follow. 

p^: (where m = i+3): the CRT number (if specified), 

p^: (where n = i+4): the page number (if specified). 

Linkage Convention 

NONHAL (1) linkage. 

Function 

The RTL UPDATE BACKGROUND routine shall construct the update 
text from the variable control words and variables, convert the text to ASCII, 
set up the parameter list for the MOSS UPDATE BACKGROUND interface, and 
issue the UPDISM SVC. (This SVC displays the supplied text to the indicated 
C&D Console page as an UPDATE message.) 

An I/O ERROR EXIT routine shall be provided in this RTL routine 
and an entry poiht to this code shall be provided in the SVC parameter list. 

Calling Sequence (DISPLAY TYPEI PROGRAM) 

CALL RTL_TlTRANS (pj, p^, p^, p^) 

Parameter List 

Pj: the TYPEI PROGRAM identified in the TYPEI PROGRAM 

library. 
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p^: the bit indicator which indicates that a CRT number and 

page number follow. . 

p^: the CRT number (if specified). 

p^: the page number (if specified). 

/ 

Linkage Convention 

NONHA L (1) linkage. 

Function 

The RTL DISPLAY TYPEl PROGRAM routine shall set up the para- 
meter list for the MOSS TYPEl PROGRAM transmission interface and issue 
the T1 TRANS SVC. (This SVC obtains the indicated TYPEl PROGRAM from 
the TYPEl PROGRAM library and transmits it to the indicated C&D Console 
and page. ) 

An I/O ERROR EXIT routine shall be provided in this RTL routine 
and an entry point to this code shall be provided in the SVC parameter list. 

CalUng Sequence (UPDATE TYPEl DATA) 

CALL RTL_T1DATA (p^, p^, p^, p^, p,, p^^, p^); 

Parameter List 


p^; the TYPEl PROGRAM identifier. 

p^; the number of TYPEl UPDATE variables. 

P 3 -P.: (where i = S+p^): the list of variable data. 

p.: (where j = i+ 1 ): the bit indicator which indicates that a 

^ CRT number and page number follow. 

p : (where k = i+E): the CRT number (if specified), 

K 

p : (where m = i+3): the page number (if specified), 

m 

Linkage Convention 

NONHA L (1) linkage. 
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Function 


The RTL UPDATE TYPEl DATA routine shall set up the parameter 
list for the MOSS TYPEl DATA transmission interface and issue the TlDATA 
SVC, (This SVC transmits the specified TYPEl UPDATE data to the indicated 
C&D Console page, ) 

An I/O ERROR EXIT routine shall be provided in this RTL routine and 
an entry point to this code shall be provided in the SVC parameter list. 
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3, 3,24 REQUEST KEYBOARD Interface 


The REQUEST KEYBOARD routine is an addition to the RTL. 
Calling Sequence 

CALL RTL__RQST_KYBD (p^, p^) 

Parameter List 


the character variable into which the KEYBOARD message 
is to be stored, 

a bit variable to be set if a message was returned. If this 
parameter is absent, the requesting task shall be delayed 
until a KEYBOARD message is available. 

Linkage Convention 

NONHA L (1) linkage. 

Function 



The RTL REQUEST KEYBOARD routine shall invoke the MOSS REQUEST 
KEYBOARD interface with the character data area address and an indicator 
for automatic wait, if specified, as parameters. If the post -variable P 2 
specified, the routine shall set this bit variable as indicated by the return code 
from MOSS. 

The address of the RTL*s I/O error processing routine shall also 
be included as a parameter to the MOSS interface. 



3. 3. 25 SELECT Interface 


The SELECT routine is an addition to the RTL. 
Calling Sequence 

CALL RTL_SELECT (p, , p , p ); 

^ XI. 

Parameter List 


The parameter list shall be formed of repeated pairs of parameters of 
the formats given below: 

Pjt the resource descriptor to be selected* The descriptor 
shall be one of the following formats: 

o Data module descriptor, 

o Program module descriptor, or 

o SPIOSI/O channel or file number. 

p^: a bit vector indicating the access rights requested for the 

resource indicated in p^. The format of the bit vector 
shall be the same as the MOSS SELECT interface (see 
Reference 7, Section 5. 5. 1 ). 

Linkage Convention 

NONHAL (1) linkage. 

Function 


The RTL SELECT routine shall set up the parameter list for the MOSS 
SELECT interface and issue the SVC instruction to invoke that service. 
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3,3,26 RELEASE Interface 

The RELEASE routine is an addition to the RTL, 
Calling Sequence 


Call r t l r lse ^ 2 ' * * * * 

Parameter List 

Each parameter in the list shall be of the same format. 

Pj : the resource descriptor of the resource to be released. 

The descriptor shall be in one of the following formats: 

o Data module descriptor, 

o Program module descriptor, or 

o SPIOS I/O channel number. 

Linkage Convention 

NONHAL (1) linkage. 

Function 


The RTL RELEASE routine shall set up the parameter list for the 
MOSS RELEASE interface and issue the SVC instruction to invoke that service. 
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3,3,27 CHANNEL CONTROL Interface 

This interface is an addition to the RTL, 

Calling Sequence 

CALLRTL_CHAN (pj, p^, P3); 

Para mete r Lisj 

the channel number of the SPIOS I/O channel being 
manipulated, 

the function indicator which selects the function to be 
performed as follows: 

1 - backspace, 

2 space, 

3 - rewind, 

4 - unload, 

5 - end file, and 

6 - close file, 

the value giving the number of files to be backspaced or for 
ward spaced. This parameter shall only be provided for 
the space and backspace options. 

Linkage Convention 

NONHA L (1) linkage. 

Function 



The RTL CHANNEL CONTROL routine shall set up the parameter list 
for the MOSS CONTROL interface (see Reference 7, Section 5,7,4), and issue 
the SVC instruction to invoke that service. The parameter list shall include 
the address of the RTL’s I/O error processing routine. 
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3. 3,28 CRITICAL SECTION Interface 

The CRITICAL SECTION interface shall consist of two routines, one 
executed at the beginning of the critical block, the other at the end of the 
critical block. The CRITICAL SECTION routines are additions to the RTL. 

Calling Sequence 

CA LL RTL_GO_CRITICA L 

Linkage Convention 

Normal HAL/S-360 linkage. 

Function 

The RTL BEGIN CRITICAL SECTION routine shall invoke the MOSS 
CRITICAL SECTION interface (see Reference 7, Section 5.4.7) with the 
enter critical processing mode parameter. 

Calling Sequence (END CRITICAL) 

CALL RTLjSTOP_CRITICAL 

Linkage Convention 

Normal HAL/S-360 linkage. 

Function 

The RTL END CRITICAL SECTION routine shall invoke the MOSS 
CRITICAL SECTION interface with the exit critical processing mode parameter. 
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3.3.29 EVENT VARIABLE Interface 

The EVENT VARIABLE interface shall be an RTL function routine 
which shall return the value of the event variable. This routine is anaddition 
to the RTL. 

Calling Sequence 

RTL_TEST (pj); 

Parameter List 

p : the event variable to be tested. 

linkage Convention 

Normal HAL/S-360 linkage. 

Function 

The EVENT VARIABLE function routine shall examine the event 
variable value to determine if it is zero or an MOSS provided event variable 
descriptor. If the value is zero, the function routine shall return a zero value. 
If the value is an event variable descriptor, the descriptor shall be passed 
to the MOSS EVENT TEST interface (see Reference 7, Section 5,3.3) via 
an SVC. The return code provided by MOSS indicates the value of the event 
variable which shall be returned by the FUNCTION routine. 
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3.3.30 TIME Interface 


This RTL routine shall replace the current HA L/S clock time routine. 
Calling Sequence 
TIME (pj)j 
Parameter List 

p^: an integer indicating the type of time value desired. 

The permissible values are: 

0 - MET time, 

1 “ GMT time. 

Return Value: a double precision floating point number equal to the value 
of the specified clock time in milliseconds, 

linkage Convention 

Normal HAL/S-360 linkage. 

Function 

The RTL TIME FUNCTION shall set up the parameter list in the 
format required by the MOSS TIME REQUEST interface (see Reference 7, 
Section 5*4,1), and issue the SVC to invoke that service. The returned time 
shall then be converted to the above specified form and returned to the caller. 
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3, 3o 31 DATE Interface 


This RTL routine shall replace the current HA L./S DATE routine. 
Calling Sequence 
DATE 

Parameter List 

Return Value: an integer equal to the value of the "days** fields of 
the GMT clock. 

Linkage Convention 

Normal HAL/S-360 linkage. 

Function 


The RTL DATE function shalT set up the parameter list in the format 
required by the MOSS TIME REQUEST interface (see Reference 7, Section 5.4,1), 
and issue the SVC to invoke that service. The required field shall then be 
extracted from the returned value, converted to the above specified form, and 
returned to the caller# 
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3, 3, 32 SPIOS Interfaces 


The I/O processing routines and macros in the HAL/S library shall 
be modified to utilize MOSS SPIOS services. These I/O routines currently 
use the OS/360 I/O services. All format conversion, line, and page manipula- 
tion logic shall remain relatively unchanged after the modification. 


The following routines and macros shall be modified; 


Routines 


Macros 


COLUMN 
FILEIN 
INPUT 
lOlNIT 
LINE 
OUTPUT 
PAGE 
SKIP 

The major impact of the modification shall consist of replacing the 
OS/360 I/O service requests with eqmvalent MOSS I/O service requests. 

The SUMC-S MOSS Application Program Design Specification (Reference 7, 
Section 5.7.1) describes the MOSS I/O service requests which shall be used. 
These include: 


FCBDEF 
FILEDEF 
HXC TL 


o READ, 

o WRITE, 

o CONTROL, and 

o CLOSE, 


The modified routines shall use the MOSS I/O ERROR EXIT routine conventions 
to handle I/O errors, Uncor rentable errors shall be communicated to the 
HAL/S error monitor to coordinate with the user defined error environment. 
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3,3.33 Interrupt and Error Handling Modules 

The modules PROGINT, ERRORMON, and ERR GRP are involved in 
the processing of program interrupts and all HAL/SM errors. These modules 
shall be modified to operate within the MOSS environment. 

The major changes to these modules shall be in how errors are 
recognized (not in how they are processed), A forced-end routine (see 
Reference 7, Section 6) shall replace the HAL/S-360 STAE routine, and a 
program exception routine shall replace the HAL/S-360 SPIE routine, l/O 
errors shall be recognized by the I/O modules via I/O ERROR EXIT routines 
specified in the individual I/O SVC’s and the specific errors shall be issued 
to ERRORMON through the normal and error intrinsic in HALSYS. 

In addition, all modules which detect and send errors may require 
change to renumber the errors they send in their invocations of ERRORMON, 
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3, 3, 34 Miscellaneous Modules 


The module HALSTART is concerned with initiation and normal ter^ 
mination of a HAL/S -360 program complex. This modiile shall be modified 
to delete certain run time JCL options which are not supported and to use 
MOSS interfaces to properly release resources (e, g, , close any open data 
sets). 


The HALSYS module and macro contain common status and linkage 
information which is required by the RTL and compiler emitted code. This 
module and macro shall be modified to reflect the reorganization of data 
and modules within the library resulting from other specific changes. 
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3. 3. 35 LOCK Interface 


The current HAL/S LOCK routine shall be modified to operate in the 
MOSS multi-tasking environment. The current HAL/S library only simulates 
a multi-tasking environment for the user programs, thus, conflicts due to 
multiple simultaneous executions of the LOCK routine in support of HAL/S 
update blocks cannot occur. In the MOSS environment, however, the HAL/SM 
library is operating in a true multi-tasking mode and it must coordinate multiple 
use of the LOCK routine. 

The MOSS SELECT and RELEASE interfaces (see Reference 7, Section 
5,5) shall be used by the LOCK routine to ensure mutually exclusive accesses 
to the lock group variable. The function of the LOCKGRP variable for 
coordinating accesses to individual data items by the update blocks shall re- 
main unchanged. The MOSS EVENT CONTROL interfaces (see Reference 7, 
Section 5,3), shall be used to suspend and signal the LOCK routine (in support 
of a specific task) when access to individual data items, as indicated by the 
LOCKGRP variable, are locked or freed. 
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3,3,36 RTL Modules to be Deleted 


The following HAL/S-360 RTL modules and macros shall be deleted 
from the HAL/SM RTL either because their functions are not supported within 
the HAL/SM system or because they have been replaced by equivalent modules 
or MOSS services. 

Modules: Macros: 


BAKTRACE 

cancel 

CLGKTIME 

CLOSE UAL, 

DATE 

DISPATCH 

DUMPHAL 

ENTERTQE 

EVENTENQ 

EXCLUDE 

EXECTRCE 

FORMA TDA 

HALSIM 

SCHEDULE 

SDLDUMMY 

SDLSTACK 

SET 

SIGNAL 

SVBLOCK 

SVBTOC 

SVDTOC 

SVETOC 

SVITOC 

SVPMSG 

SVSIGNAL 

SVSTOP 

SVTDEQ 

SVTENQ 

SVTIME 

SVVSTP 

TERMIN 

TERMINT 

TERMPCB 


COUNT 

EVXQDEF 

HALSIM 

PCBDEF 

SDLCALL 

STPGEN 

TIMQDEF 

TRACEX 
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Modules} 


TIME GANG 

TIMEINT 

TXMSMO 

UPPRXO 

WAIT 

WAITDEP 

WAITFOR 

WHERE 



3.4 


User 


This subsection discusses the user interface to the HA-I-i/SM system 
in terms of OS and MOSS JCL general requirements. The specific definition 
of the complete user interface shall be defined in a "HALi/SM.User*« 

Manual" which shall be published by the implementors. 

3. 4. 1 OS JCLi Procedures 

Cataloged procedures shall be provided to perform HAL/SM pre- 
processing, compilation, and linking in a manner similar in form and in- 
tent to the HAL/S prototype cataloged procedures (see Reference 5) HALSC, 
HALSCL, and HALSL. When HAL/SM modules have been properly compiled 
and linked they must be put in a form suitable for processing by the MOSS 
Linker. A utility and procedures for use shall be supplied with the MOSS system. 
Standard IBM utility programs may be used to place the C&D Display Message 
Data Set on a medium suitable for transfer to the SUMC-S. 

3.4.2 MOSS JCL 

MOSS jobs containing HAL/SM software shall follow all the normal 
conventions for MOSS JCL (see Reference 7, Section 3). In addition, certain 
conventions must be followed in specifying the following items; 

o Job name s. 

o Task names. 

o Program flag names. 

o Critical sections. 

o Forced- end routines, 

o Error processing routines, 

o File names. 
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4 


RESTRICTIONS AND LIMITATIONS 


Any programming system has certain characteristics which are 
specific to its implementation. In the particular case of HAL/SM, the decision 
to adapt the HAL/S-360 compiler system using a preprocessor and a modified 
run time library shall have an impact on the usability of the system which 
needs to be clearly recognized. This section briefly discusses some of the 
effects which are apparent at this time, 

4, 1 HAL/S Dependencies 


The ground rules of this implementation require that the HAL/S«360 
compiler remain unmodified. This has both advantages and disadvantages. 

On the positive side this means that any upgrades to the compiler which would 
improve its efficiency, accuracy, or correctness can easily be incorporated 
in the HAL/SM system. On the other hand, these same upgrades may change 
the syntax and/or semantics of the HAL/S language and, thereby, make it 
unusable within the HAL/SM system. The modifications made to HALLINK 
and the RTL may also make it impractical to utilize future upgrades to 
these programs as well, 

4, 2 Separation of Host and Target Machines 

The host system for the HAL/SM language processor system shall be 
an IBM S-360/370 series machine running under some version of OS/MVT, 
as mentioned previously. The target system shall be the SUMC-S running 
under MOSS, These two systems are quite different in concept and, in 
addition, they shall most likely be separated physically and managerially. 

This means that the HAL/SM programmer must be familiar with two different 
systems and sets of operating procedures before he can use the HAL/SM 
language. He must also deal with the cumbersome and time consuming problem 
of transferring his program between the two systems for every compile and 
test sequence during program development. One possible remedy to this 
problem might be a software emulator for MOSS running on the S/360, 

4, 3 Diagnostic Capabilities 

The ground rules of this implementation require that no processing 
be performed in the preprocessor which can be performed by the compiler. 

This implies that the preprocessor shall not perform a complete syntax analysis. 
The major drawback to this approach is that only a subset of the syntax errors 
will be diagnosed by the preprocessor and related directly to the HAL/SM 
program. All remaining syntax errors are caught by the compiler which 
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can only state the diagnostic information in terms of the transformed HAL/S 
text. The programmer is forced to examine listings from both language 
processors, be familiar with both languages, and be able to relate errors 
in the HAL/S program to be corresponding HAL/SM construct and determine 
where the error lies there. Since some HAL/SM constructs require consider- 
able manipulation, and some transformations are performed independent of 
context, the required correction may not always be readily apparent, A 
possible solution might be to require the preprocessor to perform a complete 
syntax analysis and verification, 

4, 4 RTL Reentrancy 

The HAL/S -360 RTL is presently not reentrant. The disadvantage 
here is that each task must have a private copy for its own use. Under MOSS, 
a reentrant RTL might be placed in the job (or system) common area of the 
address space and shared by all HAL/SM tasks within the job (or system) 
at a considerable savings in memory requirements and execution time (due 
to reduced paging). However, making the RTL reentrant would probably 
require a major (if not complete) rewrite of this software. 
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